More and more organizations are exposing their technology-based business capabilities to external consumers, business partners, and/or others, through so-called Application Programming Interfaces (APIs). In this regard, APIs generally provide services in a wide range of different technology areas and for a wide variety of different possible end uses. For instance, LinkedIn allows companies to utilize candidates' CVs during their application processes, e.g., by offering the information stored within the LinkedIn platform (and storage locations thereof) through public APIs. As another example, Salesforce.com helps companies manage their entire sales processes, e.g., from lead generation to post-sales relationship management, through APIs and mobile device integration. In still another example, MasterCard offers APIs for bill payment and fraud detection services, as well as for enabling consumers to search for the closest ATM.
It will be appreciated that the advent and proliferation of smart devices, mobile apps, and the like, as well as the broad availability of the Internet, has challenged organizations to make such capabilities accessible from almost any location and at almost any point in time. As a consequence, and as will be appreciated from the three brief examples provided above, organizations oftentimes find themselves offering their formerly internal Information Technology (IT) endpoints to a growing number of external consumers.
In an effort to try to reduce vulnerabilities in local IT systems, some organizations create new applications directly within a distributed computing environment such as, for example, a cloud computing environment. Although there are many competing definitions for “cloud computing,” it generally involves (1) the delivery of computing as a service rather than a product, and (2) providing shared processing and/or storage resources, software, information, etc., to computers and other devices as an oftentimes metered service over a network (typically the Internet). In a cloud computing environment, end users do not necessarily need to know the physical location and configuration of the system that delivers the services. Applications typically are delivered to end users as the service, enabling transparent access to the cloud-based resources.
The nature of cloud computing oftentimes makes it easier for consumers to adapt to new applications provided through the cloud, e.g., as compared to newly exposed internal endpoints. The former oftentimes simply involves the creation of a new account by logging on through a web browser or mobile app, whereas the latter oftentimes instead involves re-developing and/or re-deploying software at the consumers' endpoints. The nature of cloud computing also oftentimes facilitates scalability for service providers that manage growing numbers of consumers and/or APIs.
Because many APIs are now exposed in the cloud, integrations that make use of cloud APIs and/or applications themselves sometimes also are moved into the cloud. This approach generally is referred to as “Integration Platform as a Service” (iPaaS) technology. The webMethods Integration Cloud from Software AG is an example iPaaS technology platform.
In a so-called “hybrid integration approach,” new APIs, along with existing applications from the backend, are provided or otherwise made available by orchestrating APIs in the cloud. This is shown schematically in FIG. 1. That is, an iPaaS platform 102 includes an orchestrating API 104. The orchestrating API 104 connects with remote APIs 106a-106x, which are respectively provided to cloud applications 108a-108x. 
APIs generally are designed in a manner that allows for easy introspection, as many organizations offering APIs for creation and/or modification of data records (as would be the case in, for example, creating a new customer using a Salesforce.com API) typically also expose such APIs for data querying purposes. The rich functionality that can be provided with APIs, combined with their more “permanent” availability (e.g., because they typically remain accessible even though the backend resources with which they interface may change), and comparatively low-barrier restrictions (oftentimes related to security concerns, compliance with Service-Level Agreements (SLAs), payment conditions, and/or the like), offers countless new possibilities for introspection, including remote introspection.
Unfortunately, however, opportunities for introspecting APIs in iPaaS and/or other related technology platforms oftentimes are limited, at least form a practical perspective. Indeed, as explained below, current commercially available products typically encounter difficulties in testing and verifying cloud-based API integrations and orchestrations.
These commercially available products typically fall into one of three different categories. First, cloud-to-cloud orchestration debugging typically is based on conventional debugging concepts but resides on top of cloud APIs (i.e., in an Information Cloud). Tools that involve cloud-to-cloud orchestration based on conventional debugging typically do not offer much new compared to local code debugging (e.g., in contexts relevant to the instant disclosure). For instance, and in contexts relevant to the instant disclosure, because tools that involve cloud-to-cloud orchestration based on conventional debugging are executed on top of cloud APIs, the debugger typically will only see whether an API call was successful (or whether an exception was encountered) while stepping through the individual integration steps.
Second, service-oriented architecture (SOA) visibility tools such as webMethods Insight introspects remote applications directly on the server, utilizing agent technology. The agents are remotely installed and typically are designed for retro-inspection and root cause analysis of exceptions that occurred in the past. Although they allow developers to see the impact of changes in a remote system, such tools generally are not appropriate or sufficient for developers because of the need to deploy agents and limitations concerning post hoc analysis.
Third, service orchestration or business process management may be performed without human interaction and with one or more additional monitoring components enabled. Such solutions typically are intended to be used in asynchronous communication patterns. In addition, for business processes (for example), the service invocation flow typically is designed from a static (e.g., at the point of deployment) point of view, and API calls typically are not calculated based on another step in the process. These features unfortunately make real time analysis difficult, if not impossible.
Other typical products available in the market allow for debugging and data introspection for objects that are under the control of the executing system. In this sense, such products typically show how variables and objects are changing and/or change over time, e.g., while the code is executed, runtime conditions are encountered, etc. However, in most cases, the related tools cannot introspect and/or debug remote data, code, applications, etc., e.g., unless they have agents installed on the relevant remote systems.
Certain example embodiments address the above and/or other concerns. For instance, certain example embodiments help IT organizations in testing and verifying cloud-based API integrations and orchestrations. This may be accomplished by providing some or all of the following and/or other features: (1) automatic or at least semi-automatic identification and provisioning of “inverse” APIs for one or more selected APIs (e.g., based on manual selection, static lists, computed or “social” intelligence, etc.); (2) integrated (e.g., side-by-side or otherwise oriented) introspection views based on the real-time invocation of inverse APIs; (3) selection of a subset of relevant inverse APIs, e.g., in the case of complex orchestrations, so as to help reduce the likelihood of developers, testers, and/or others from becoming flooded with too much information; and (4) provisioning of these and/or other features without remotely deployed agents, e.g., such that remote systems need not be “touched” or accessed other than via public APIs. It follows from the above that because it is possible that more than one inverse API may be selected, inverse APIs in certain example embodiments may not be exposed by the same system or vendor as the API in order to be called. Furthermore, in certain example embodiments, because debugging and/or application introspection typically are performed in real-time, the inverse API also may be executed in parallel and provide results in real-time.
One aspect of certain example embodiments relates to helping API orchestration developers, testers, and/or others easily introspect remote applications exposed through public APIs. It will be appreciated that introspection may relate to, among other things, querying the API of the same or another party in order to verify immediate and/or indirect impact(s) on a cloud application that has been directly and/or indirectly invoked through an API call, e.g., when creating or updating data.
Another aspect of certain example embodiments relates to techniques for debugging cloud APIs in a non-invasive manner, e.g., without the need for static debugging code being deployed and avoiding the overhead associated with such an approach.
Another aspect of certain example embodiments relates to the deployment of inverse APIs to allow inspection of applications through their APIs, e.g., in a cloud integration or other distributed computing environment.
Certain example embodiments address the technical problem of how to test and/or otherwise introspect applications (or aspects thereof) deployed in a distributed computing environment (such as, for example, a cloud computing environment) where one does not have full control over the system under test. For example, various cloud providers and companies that distribute applications have a wide variety of associated APIs, and certain example embodiments help address the issue of how to test the results of calling these APIs in a non-invasive manner (e.g., without specific static debugging code being included directly in the remote systems under test). More particularly, certain example embodiments include the deployment of reverse APIs that allow remote application introspection to be performed so that, for example, the effects of calling an API in the cloud can be seen through the calling of a corresponding inverse API that is supported and provided by the application in question. This approach can in some implementations advantageously provide more than the mere changes to a given variable that results from an API call, and instead can provide information concerning a whole set of changes, e.g., based on the change to the variable and its consequences, without the need for static invasive debugging code and without the overhead implied by such code.
In certain example embodiments, a distributed computing system is provided. The system includes a plurality of first computing platforms, with each said first computing platform comprising an interface and first processing resources including at least one first processor and a first memory, and with the first processing resources of the respective first computing platforms being configured to perform operations in response to instructions received over the respective interfaces. The system also includes an integration and introspection computing platform comprising second processing resources including at least one second processor and a second memory, with the integration and introspection computing platform being located remote from the first computing platforms. The second processing resources are configured to control the integration and introspection computing platform to at least: send first instructions to the first computing platforms to cause the first computing platforms to perform first operations in accordance with orchestration logic; send second instructions to the first computing platforms to cause the first computing platforms to perform second operations in accordance with introspection logic, the second operations being defined as inverse operations of at least some of the first operations; receive from the first computing platforms results from the performance of the second operations; and correlate the received results and the corresponding first operations.
Corresponding methods and non-transitory computer readable storage mediums tangibly storing instructions for performing such methods also are provided by certain example embodiments, as are corresponding computer programs.
In certain example embodiments, there is provided a method of debugging and/or introspecting an integration deployed in a distributed computing environment. The integration is defined to include a plurality of operations performable responsive to receipt of instructions from an orchestrating system by public interfaces of computing systems of the distributed computing environment. The orchestrating system is located remote from the computing systems. An inverse operation for at least some of the performable operations in the integration is identified. The inverse operations also are performable responsive to receipt of instructions from the orchestrating system by the public interfaces of the computing systems of the distributed computing environment. Each inverse operation is structured to reveal, upon its performance, an effect of one or more associated performable operations. The orchestrating system is able or otherwise configured to send instructions to the public interfaces of the computing systems to cause the performable operations and their associated inverse operations, if any, to be performed in parallel with one another via processing resources of the computing systems, in debugging and/or introspecting the integration.
Corresponding systems and non-transitory computer readable storage mediums tangibly storing instructions for performing such methods also are provided by certain example embodiments, as are corresponding computer programs.
In certain example embodiments, there is provided an orchestrating system for debugging and/or introspecting an integration deployed in a distributed computing environment. The integration is defined to include a plurality of operations performable responsive to receipt of instructions from the orchestrating system by public interfaces of computing systems of the distributed computing environment. The orchestrating system is located remote from the computing systems. The orchestrating system comprises processing resources including at least one processor and a memory, the processing resources being configured to control the orchestrating system to at least: control the computing systems to perform the integration; facilitate identification of an inverse operation for at least some of the performable operations in the integration, the inverse operations also being performable responsive to receipt of instructions from the orchestrating system by the public interfaces of the computing systems of the distributed computing environment, each inverse operation being structured to reveal, upon its performance, an effect of one or more associated performable operations; and (a) send instructions to the public interfaces of the computing systems to cause the performable operations and their associated inverse operations, if any, to be performed in parallel with one another via processing resources of the computing systems, and (b) receive results from the performance of the inverse operations from the public interfaces of the computing systems, in debugging and/or introspecting the integration.
Corresponding methods and non-transitory computer readable storage mediums tangibly storing instructions for performing such methods also are provided by certain example embodiments, as are corresponding computer programs.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.